﻿
<h2>Introduction</h2>

<p>In Part 1 of this article series, I created a class that sends a separate event for each <code>NotifyFilter</code> 
item in the DotNet <code>FileSystemWather</code> object.  In this article, I'll discuss the ramifications of using this 
class, and some quirks regarding the functionality of the <code>FileSystemWatcher</code> object.  This article is more 
a series of screen shots and relevant discussion rather than an examination of code, so if you're not inclined to read 
this, don't feel too bad about it. However, I would recommend that you do read this one, because it reveals what I 
consider to be "good-to-know" info.</p>

<p>We won't be exercising the folder existence code in this article, and instead will be focusing on the standard 
events that are spewed out by the DotNet <code>FileSystemWatcher</code> object.</p>

<p><b>Note:</b> I'm using Windows7 Ultimate (64-bit). I don't know if tyou'll see different results on older versions of 
Windows. I see no reason why you should, but hey, who knows?</p>

<h2>Before We Start</h2>

<p>First, I assume that you downloaded the source code/ demo application from Part 1. If not, and if you'd like to sing 
along, please download that code now.  Since the release binary is included with the project, you may simply run it 
(there's no need to fire up the IDE and compile it).</p>

<h2>Some Interesting (For Me) Discoveries</h2>

<p>When we fire up the demo application, we are greeted with the following form.</p>

[PART2_IMAGE_01]

<p>The textbox is automatically populated with a folder that exists on my system. Your first action should be to change 
this value. You can use the browse button to find an appropriate folder. You may want to change the hard-wired path value 
to something that reflects your own drive\folder hierarchy so that the default folder is more appropriate for you, but 
you'll have to change the code (in the form) and recompile if you want to do this. Remember, it's just a demo app and not 
all of the expected bells and whistles haven't been implemented.</p>

<h3>Creating a File</h3>

<p>There are several ways to create a new file in a folder.  As expected, simply right-clicking in the folder and selecting 
"New Text Document" from the context menu results in a single event.</p>

[PART2_IMAGE_02]

<p>However, this is what happens when you create a new file from NotePad.</p>

[PART2_IMAGE_03]

<p>Holy Crap!  That's a LOT of events for simply saving a new file from Notepad. I chekced the debug trace and that's 
apparently the order in which the events are really fired.  In this case the file was only 7K, so the events appeared 
to all fire at pretty much the same time.  You would think that would explain why the time of the event appears to be 
the same, but check this out:</p>

[PART2_IMAGE_04]

<p>This output was generate when I tried to save a 7mb file from NotePad. In real time, it took 14 seconds to get the 
last event generated by saving such a large file. And if you think Notepad is messed up, check out the results of 
creating a new file from Microsoft Work 2007:</p>

[PART2_IMAGE_05]

<p>Man, I never knew there was so much going on behind the scenes in Microsoft Word.  let's check out savig a new 
file from PaintShop Pro...</p>

[PART2_IMAGE_06]

<p>Granted, that's a little better, but still, notice the repeated <code>Created</code> event (a common theme). As if 
that's not weird enough, here's what happens when you copy a file from a folder on the same hard drive into our 
watched folder.</p>

[PART2_IMAGE_07]

<p>I don't see anty <code>Created</code> events at all, despite the fact that the file was "created" in the folder. 
Here's what happens when you copy a file from a different hard drive.</p>

[PART2_IMAGE_08]

<p>Finally, I downloaded a file with FireFox into the watched folder, and got these results.</p>

[PART2_IMAGE_09]

<p>I don't know about you, but I'm tired. :)</p>

<h2>It Boggles The Mind</h2>

<p>Personally, I think the <code>FileSystemWatcher</code> object is - for lack of a better term - just plain wacky. 
The bizarre aspect of this is that it's not really the fault of the object, becausae it's merely reporting what's 
happening in the folder.  I suppose what we've learned here is that how you handle the object's events depends 
COMPLETELY on how (and by what mecahnism/application) you expect the files to be placed in the watched folder. In 
light of this realization, you could make use of this demo application so that you can investigate your own 
requirements and design acohesive plan for handling those events in whatever manner you might choose. The upside 
is that now you don't have to perform nearly as many reactive changes in the code in order to handle all of your 
expected file types (and their source applications/mechanisms).  Hapy hunting, and good luck.</p>

